The present invention relates to conversion and routing of data, and in particular to conversion and routing of data on a communications medium such as the World Wide Web (WWW) or the Internet.
The amount of content on the World Wide Web (WWW), as well as the number of users, continues to increase. Although the capacity of the network carrying electronic traffic between the WWW servers and users is also growing, this alone is not enough to avoid congestion on the Internet. Ways of optimizing the network usage are desirable.
Use of the WWW and of wireless communicators, such as telephones and electronic personal assistants, has increased and today these electronic communication techniques have begun to merge. At the same time, the number of different types of electronic devices used to access the WWW is also increasing. Optimizing network usage is even more beneficial in the wireless environment where the network connection's bandwidth is limited. Mobile devices may also have limited resources in comparison to desktop computers. For example, mobile devices often have smaller screens, a less powerful CPU, and less memory in comparison to regular desktop computers. The wireless network can also be less reliable and can be slower than a fixed network. Communication networks are particularly well suited to content adaptation services that can allow faster delivery of content as well as proper presentation on a wide range of devices, whether wireless or otherwise.
Communications networks typically include servers that provide information and clients that access the servers to obtain information. Proxy servers may be used within a communication network to facilitate communication transactions. For example, proxy servers can perform caching functions to expedite delivery of content. A proxy generally transmits data between a client and a server in response to a user request for content. A client that would usually communicate directly with a server can instead contact a proxy. The proxy can then contact the server that holds the requested information. After receiving the client request, the proxy can open a connection to the server and transmit the request to the server. The proxy waits for a response from the server, which the proxy transmits to the client.
Proxies can also enable communications between a client and a server that cannot communicate directly, and/or provide enhanced functionality to client/server communications. For example, a proxy may cache server responses to specific requests. By caching server responses, if the request is repeated, a response may be returned directly by the proxy without making a new connection to the server. Proxies can also be used to alter the data flows between a client and a server.
It may be more desirable to deploy some services in proxies rather than in origin web servers. Proxies may include services that facilitate adaptation of content and enhance web page access performance. The Open Pluggable Edge Services (OPES) environment allows services to be added at the proxy server that can extend the functionality of the proxy server. For example, OPES can enable proxy servers to provide services that mediate, modify and monitor object requests and responses.
The OPES architecture is described in “Extensible Proxy Services Framework” Internet-Draft: draft-tomlinson-epsfw-00.txt by G. Tomlinson et al. which is herein incorporated by reference in its entirety. FIG. 1 shows an example of the OPES architecture including a user agent 110, a caching proxy server 120, and a content server 130. An OPES engine is typically implemented at the caching proxy server 120. The OPES engine defines only four external execution points known as client request 1, proxy request 2, origin server response 3, and proxy response 4. The client request 1 represents a request by a client 110 or “user agent” to the caching proxy 120 on an inbound flow. The proxy request 2 represents a request by a caching proxy 120 to a content server 130 on the inbound flow. The origin server response 3 represents a response from a content server 130 to the caching proxy 120 on an outbound flow. The proxy response 4 represents a response from a caching proxy 120 to the client 110 on the outbound flow. The flow of HTTP user request messages and response messages between the user agent 110, the caching proxy 120, and the server 130 is represented by arrows. A user request for content is typically generated by a client/user agent 110 when a user either types a URL in a browser or clicks on a hypertext link. When the user request reaches the caching proxy server 120, the caching proxy server 120 can retrieve requested data or content from a cache in the caching proxy server 120 if the requested data or content is already available at the caching proxy server 120. If the requested data or content is not already available at the caching proxy server 120, then the caching proxy server 120 forwards the user request to the origin server 130 containing the requested data. When the content is retrieved, the proxy server 120 forwards the data to the user agent 110.
An OPES environment is typically implemented in the proxy server 120. Services are defined with proxylets and rule modules together with general services provided by the proxylet library. A proxylet is an executable code module that has a procedural interface to core services of a caching proxy. An event can occur at any of the four execution points that triggers a proxylet to process the message. Proxylets may either be downloaded from content servers or user agents or may be preinstalled on a caching proxy. A proxylet library is a language binding dependent API on the service environment caching proxy platform with which proxylets link. A proxylet library can provide a standardized and strictly controlled interface to a service execution environment on the proxy.
The OPES environment also adds message parsers, a rule processor, and sets of actions. The message parser (not shown) processes the message stream flowing between the client 110 and the content server 130 and can extract message properties relevant to a rule base. These message properties can then be fed through the rule processor (not shown) with an appropriate rule module. The message parser is thus responsible for interpreting messages received, isolating salient elements as message properties, and causing actions to be activated when appropriate. When a trigger occurs, an event context is established containing the relevant properties isolated by the message parser.
The rule processor is invoked by the message parser at an event and is responsible for activating applicable rules in a rule base. The rule processor activates a rule by determining whether the pattern of the rule matches the event properties in a given event context, and if so, invoking the corresponding action. A rule base can include a collection of rule modules. Each rule module can include a set of rules. Each rule comprises a pattern and an action. A pattern is an expression that can be evaluated with respect to the message properties in an event context. Actions can identify proxylets, built-in proxy library functions or remote call outs that can modify operation of the service environment caching proxy.
The rules will either match or fail to match the properties in a particular event context. A rule is matched if the message properties match those specified in the rule. The matching of a rule results in a trigger that causes an action to occur, such as execution of a proxylet, an action built into the proxylet library, or a call out to a remote call out server for help processing the message. Salient components of the message are passed to the proxylet, built-in action function, or to a remote call out server via a network protocol.
Proxylets, built-in actions, or remote callout servers may inspect, add, delete, and modify the properties of messages identified by message parsers, within constraints defined by the message parser. The results of processing are passed back to the service execution environment for disposal. The service execution environment may cache the result or throw it away and send an error message to the user agent or content server. After action execution is completed, the service execution environment does not modify the message further.
The OPES architecture is relatively rigid in that OPES defines a fixed set of four processing points. Moreover, OPES allows only externally visible processing points because OPES is concerned with interoperability of implementations from different vendors. The rigidity of the OPES architecture can make scaling difficult. Another constraint of the OPES architecture is that OPES requires its own message parser, a current HTTP address and RTP/RTSP messages.
Most knowledge-based systems evaluate all the facts and rules in all circumstances. This method is general and comprehensive, but can result in poor performance. The OPES architecture has a rule base that includes only a fixed set of simple default rules that dictate the order in which different services should be applied. OPES rules are relatively loose and message-oriented, and the logic of the rules is procedurally expressed. For example, an OPES rule can read: if message X is received, and if it has attribute Y, do action Z. Application of these rules typically depends on the direction a message is flowing (inbound/outbound) and who is the owner of the rules, for example, a client, a content author, or a service provider. The OPES rule processor starts out with a set of all rules and narrows the set of all rules to a subset of rules applicable in the particular processing point. At run time, an OPES rule specifies which processing point is associated with that particular OPES rule. Thus, the OPES rule processor evaluates all rules in a rule base. When the rule base is very large, serially searching through all of the known rules can be inefficient.
There is a need for systems that can efficiently adapt or transform content for presentation on a variety of end user devices.